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(57) A system and method for storage and retrieval 
of both time-oriented versions and view-orien- 
ted versions of engineering change information 
in which the engineering change information 
progresses through a set of status conditions 
and access to the data by different user groups 
is conditioned upon the status of the infor- 
mation. Version control software logic enables 
users to create vers ion ed objects by logical key 
grouping of data elements. The version control 
logic acts upon the logical keys and special 
versioned attributes of these objects for the 
proper specification and selection of object 
instances during creation, update or retrieval 
processing. Insert and extract sequence num- 
bers are automatically generated for both his- 
torical preservation of previous engineering 
change information and efficient retrieval of the 
currently effective designs. Instance level sec- 
urity facilitates the merger of different versions 
of the engineering change data having different 
engineering change status levels so that similar 
types of data can be contained within a single 
data base table. 
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The present invention relates to automated 
engineering management systems in general and 
more particularly to a method and system for estab- 
lishing version control of engineering changes in 
order to keep track of all data pertaining to engineer- 
ing changes. 

Most manufactured products pass through a 
period of development during which the design data 
is very volatile. During this period, alternative designs 
for assembly items and their component items may be 
under consideration simultaneously. Each such alter- 
native design may be stored in the data base as an 
independent version or iteration of the item before a 
selected design is authorized to be released via an 
engineering change notice (EC). This is an example 
of a non-engineering change controlled item which 
needs to have multiple versions. 

An engineering change is used to package 
designs or design modifications that are related as, for 
example, all modifications to an original design 
necessary to improve the design. A single engineer- 
ing change may affect different pieces of data on dif- 
ferent items. It can result in the addition of one or more 
bill of material components on one part and create 
item data for the component item. It can also change 
a drawing reference on another part. 

Once a design is selected, and an engineering 
change authorizes a new item to be released to man- 
ufacturing, the item is said to be under engineering 
change control. Subsequent changes to the same 
item are authorized by new engineering changes. 
Version control methods are used to maintain a his- 
tory of all engineering changes. The types of 
engineering change data that need version control 
include item engineering data, components in bills of 
material, optional components, local substitute com- 
ponents, item responsibility data, sources of supply, 
reference documents, manufacturing lead time and 
yield, routing and operation, notes and comments. 
Engineering change data is further classified by its 
status such as pre-release, release, accepted by 
manufacturing and currently effective status. In pre- 
release status, design engineering data is being 
defined and reviewed by the design group. Release 
status indicates that a formalized engineering design 
has been released to manufacturing by the design 
group. Accept status is obtained when the released 
data has been reviewed by the manufacturing 
engineer or manager. At this stage in the design life 
cycle, additional manufacturing data can be added to 
the released data. Effective status is achieved when 
the released data is ready to be incorporated into pro- 
duction. 

There are several known ways of storing the his- 
torical sequence of changes to data elements. The 
most detailed method treats every data element inde- 
pendently and stores both "before" and "after" images 
of every data element that has been changed. Several 



data base management systems use this approach 
for data base recovery purposes. It optimizes data 
storage but is inefficient for data processing. An 
opposing method includes all version controlled data 

5 elements in a single large object. Thus a change to 
any data element requires "before" and "after" images 
of the entire object. This second approach makes the 
processing logic very complex and wastes large 
amounts of storage space unless the types of data 

10 and the number of data elements in the object are 
limited to a manageable number. 

Having adopted this second approach, commer- 
cially available products for version control for track- 
ing engineering changes have been limited to bills of 

15 material (BOM) in released status only. Engineering 
change data in pre-release status, if any, are kept in 
a duplicate file or data base table so that the same 
computer program can be used for both. The most 
common version control technique used is known as 

20 date effectivity in which a range of effective dates is 
specified during which a released bill of material com- 
ponent can be used in an assembly. This information 
is stored in the computer system as an occurrence or 
instance of a specific bill of material component 

25 object. The ranges of effective dates are stored as 
attributes of the bill of material component object. 
These dates are then used for the selection of a speci- 
fic occurrence or version of a bill of material compo- 
nent. Overlapped ranges of effective dates for 

30 different versions of the same component are not per- 
mitted. References to the engineering changes which 
added and removed the bill of material components 
are included as optional attributes and are not used 
for version control. No distinction is made between 

35 non-engineering change controlled and engineering 
change controlled versions of items or between pre- 
release and released versions of items and bill of ma- 
terial components. 

A typical implementation of pre-release data for 

40 bill of material components is the use of a separate 
data base or file to contain the pre-release data which 
avoids the need to implement additional version con- 
trol techniques. This is an inefficient implementation 
since at the time of engineering change release the 

45 pre-release data must be copied over to the data base 
or file containing the released data. 

Traditionally, most commercially available 
software products were developed using date effec- 
tivity for version control of bills of material. Examples 

so are IBM Corporation's COPICS (Communications 
Oriented Production Information and Control System) 
and MAPICS (Manufacturing Accounting and Produc- 
tion Information Control System) families of products. 
More recently, some of the commercially available 

55 products have been modified to handle serial number 
effectivity in order to track "as built" product configu- 
rations to satisfy statutory accounting requirements. 
An example of such product is IBM Corporation's 
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"COPICS Defense" product. Such modified software 
products replace a range of effective dates by a range 
of serial numbers for version control. These version 
control techniques are limited to released versions of 
bill of material components only. Version control of 5 
other item related and bill of material related data and 
having a status other than release has not been 
implemented. 

It is an object of this invention to provide a method 
for version control of engineering change data that 10 
enables the storage and retrieval of versioned data 
having varying effectivity characteristics, such as 
time-oriented effectivity, view-oriented effectivity or 
combinations thereof. 

It is another object of this invention to provide a 15 
method for improving the processing efficiency of ver- 
sioned data stored in a relational data base table in 
which the different versions of data can each have a 
different engineering change status. 

It is a further object of this invention to provide an 20 
adaptive version control system that enables the stor- 
age and retrieval of multiple categories of version- 
controlled engineering change data. 

These and other objects and advantages are 
accomplished by the present invention in which 25 
software logic operates on versioned objects which 
are constructed by appropriate grouping of data ele- 
ments. When any attribute of a versioned object is 
changed, a new instance of the same object is 
created. A versioned object uses a logical key to iden- 30 
tify the group of object instances that are considered 
to be different versions of the same object. For 
example, a versioned item is uniquely identified by the 
item identifier as the logical key; a versioned bill of ma- 
terial component is uniquely identified by a combi- 35 
nation of bill of material item identifier, component 
item identifier, and sequence number as the logical 
key. These attributes will be described below in con- 
junction with the description of the preferred embodi- 
ment. 4 q 

The software logic implements different types of 
version control through a set of object attributes 
including system generated design sequence num- 
bers and user defined view identifiers. The design 
sequence number of an item affected by an engineer- 45 
ing change (referred to as an affected item) is recor- 
ded as an insert sequence number for new instances 
of objects for which at least one attribute has 
changed. A previous version of a superseded object 
is not physically deleted. Instead, it is extracted by so 
recording the design sequence number of the new 
instance of the affected item as the extract sequence 
number for the previously unextracted instance of the 
affected item object in the same view. 

A better appreciation of these and other advan- 55 
tages and features of the present invention, as well as 
the manner in which the present invention realizes 
them will be gained from the following detailed des- 



cription and accompanying drawings of the preferred 
embodiment, and from the claims. 

Figure 1 illustrates a block diagram implemen- 
tation of the components of this invention. 

Figure 2 illustrates the relational data base files 
pertaining to engineering changes that are version 
controlled and the other files that assist in version- 
control processing. 

Figure 3 illustrates a matrix for object instance 
data access authorization based on engineering 
change affected item status level. 

Figure 4 illustrates the effect on versioned files 
resulting from the creation of an engineering view of 
a new assembly in pre-release status. 

Figure 5 illustrates the effect on versioned files 
resulting from the replacement of one bill of material 
component by another component. 

Figure 6 illustrates the effect on versioned files of 
promoting an engineering change from pre-release to 
release status. 

Figure 7 illustrates a method of allocation of 
design sequence numbers to engineering change 
affected item status levels. 

Figure 8 illustrates the effect on versioned files 
resulting from changing the standard unit of measure 
for an assembly item. 

Figure 9 illustrates the effect on versioned files 
resulting from promoting an item from released to 
accepted status and changing effectivity data. 

Figure 10 illustrates the effect on versioned files 
resulting from the creation of a location view of the 
assembly. 

Figure 11 illustrates a user interface display menu 
having a list of user-selectable options for retrieval of 
versioned data. 

A block diagram implementation of the compo- 
nents of the preferred embodiment of this invention is 
illustrated in Figure 1. As shown in this figure, the ver- 
sion control system 1 0 includes a version control com- 
puter program 20 which operates on computer 
processor 30. Design engineers and other groups of 
users at terminal device 1 8 interact through processor 
30 with relational data files stored on direct access 
(non-volatile) storage device (DASD) 40. Perma- 
nently stored on DASD 40 are engineering change 
notices file 12, master item file 14, engineering 
change affected item file 16, item related data files 22 
and bill of material related data files 24. Version con- 
trol logic 20 controls the storage and retrieval of ver- 
sioned engineering change data. 

A design engineer using terminal device 18 
creates engineering change notices 12 which can be 
divided broadly into three categories: notices affect- 
ing item related data 22, notices affecting bill of ma- 
terial related data 24, and notices affecting both item 
related data 22 and bill of material related data 24. All 
item related data 22 and bill of material related data 
24 are controlled by the version control logic 20. The 
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data in engineering change notices file 12, master 
item file 14 and engineering change affected item file 
16 are not versioned, but assist in control of the ver- 
sioning process. The engineering change affected 
items in file 16 represent the relationship between 
each notice in engineering change notices file 12 and 
all master items in master item file 1 4 that are affected 
by the engineering change. The versioning control 
process occurs when an affected item is created and 
stored in engineering change affected item file 16, 
and any item related or bill of material related data is 
added to or changed in either item related data file 22 
or bill of material related data file 24. Note that data is 
not physically deleted except for the archival of obso- 
lete data. 

The present invention provides version control 
logic 20 that can process different types of objects that 
are constructed by any desirable grouping of required 
data elements. This enables a balance to be achieved 
between storage economy and processing efficiency. 
Well known data base design principles may be used 
to define versioned objects, such as normalization of 
data for relational databases. When an attribute of a 
versioned object is changed, a new instance (occurr- 
ence) of the same object is created. However, no new 
instances of an object are created in cases where 
none of the attributes have changed. The implemen- 
tation of the desired level of storage economy is 
accompanied by an efficient implementation of ver- 
sion control logic to achieve the balance between 
storage economy and processing efficiency. 

The version control logic 20 provides means to 
handle the complexity of processing many types of 
versioned objects and of supporting many types of 
version-controlled functions as explained below. The 
version control logic 20 is insulated from the different 
types of objects that need to be version-controlled. 
Taking advantage of the similarity in behavior of 
object attributes, a class of objects with versions (ver- 
sioned objects) is used to capture the common 
behavior of both engineering change controlled 
objects and non-engineering change controlled 
objects. 

Figure 2 illustrates examples of item related data 
objects 22 and bill of material related data objects 24 
that can be versioned. The figure shows data relation- 
ships rather than data flow. The arrowheads indicate 
one-to-many data relationships. The connecting lines 
without arrowheads indicate on-to-one relationships. 

Versioned data types contained in item related 
data files 22 include the following: 

1. item engineering data 50, such as item type 
and unit of measure; 

2. item association data 52, such as the catalog 
part number; 

3. item responsibility data 54, such as the depart- 
ment and/or engineer responsible for the item; 

4. item references data 56, such as engineering 



drawings and technical specifications; 

5. item sources of supply data 58, including plants 
and supplier information; 

6. item manufacturing data 60, such as lead time 
5 and yield; 

7. item and bill of material comments 62 that 
include textual notes; and 

8. item routing data 64, including alternate rout- 
ings as appropriate. 

10 Versioned data types contained in bill of material 

related data files 24 include the following: 

1. bill of material header data 66, such as instal- 
lation code and batch size; 

2. bill of material components data 68 including 
15 the quantity per assembly; 

3. optional and substitute components data 70 
including selection preferences and local sub- 
stitutions; and 

4. component manufacturing data 72, such as 
20 parent item operations where the components 

are used. 

Each of these versioned data types may be 
defined as a persistent object that is physically stored 
in a single relational data base table stored on DASD 

25 40. All versions of object instances pertaining to each 
engineering change are contained in these relational 
data base tables. Object instances having different 
engineering change status (i.e., release, accept, etc.) 
coexist in the same relational data base tables without 

30 having to copy data from one table to another when 
the status changes for a specific engineering change. 
The version control logic 20 provides instance level 
security that limits access to stored engineering 
change data by different groups of users based on 

35 engineering change status levels. 

The use of instance level security to control 
access to engineering change data at different 
engineering change affected item status levels is 
shown in Figure 3. The security implementation can 

40 vary based on user group requirements, but, in gen- 
eral, information about products in a development 
stage (pre-release status) that is accessible by design 
engineers should be at a more restrictive security 
level than information about products that are fully 

45 developed (released status) and that is accessible by 
manufacturing engineers. Figure 3 indicates that 
design engineers belong to a user group that has 
access to data at security level 05 which is the most 
restrictive in this embodiment. Design engineers also 

so have access to data at the less restrictive security 
levels 01 through 04. Similarly, manufacturing 
engineers have access to data at security levels 04 
and lower corresponding to engineering change 
affected items 16 in a status of release. Production 

55 planners have access to data at security levels 03 and 
lower corresponding to engineering change affected 
items 16 that have been "accepted" by the manufac- 
turing group. The production control group has 
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access to data at security level 02 that has been made 
effective by manufacturing. Finally, once the affected 
items in an engineering change are closed, data 
access at the least restrictive security level 01 is pro- 
vided to an archival library user group. 

In order to implement instance level security, a 
security level attribute is associated with each object 
instance. Using database terminology, this is equival- 
ent to requiring that every row in a relational data base 
table have a security level column. By judiciously 
combining EC affected item status with instance sec- 
urity levels as explained above, different groups of 
users, having access to data at different status levels 
for the EC affected items, are presented with different 
views of the stored data. 

Figure 4 illustrates the effect of an engineering 
change notice (referred to as ECA) that creates both 
item engineering data 50 and bill of material compo- 
nent data 68 for a new assembly "A" in pre-release 
status in the design engineering view. Other item 
related data 22 and BOM related data 24 are similarly 
created and version controlled. The EC affected item 
file 16 contains the relationship between engineering 
change and item, version control data, and item effec- 
tivity data. 

The first entry in EC affected item file 16 in Figure 
4 has an EC identifier "ECA", an item identifier "A", 
and affected item status of pre-release. The user 
defined view identifier "Engl" specifies that this view 
of item A is an engineering view. The system gener- 
ated design sequence number "8001" establishes a 
unique relationship between ECA and item A. Item 
effectivity data includes planned effectivity type 
"Date" and planned effectivity start date of "3-1-90". 
The product identifier "P1" specifies that assembly A 
is used in product P1. 

Since ECA is the inserting engineering change for 
item A in engineering data file 50 and BOM compo- 
nent data file 68, the design sequence number 8001 
is recorded as the insert sequence number for both 
types of data. The logical key for item engineering 
data is the item identifier. A combination of assembly 
item identifier and component item identifier provides 
the logical key for bill of material data. In this example, 
assembly A has components B, C, and D, as indicated 
in bill of material file 68. In addition to the logical key, 
which is available within any data object, a view iden- 
tifier, insert sequence number and extract sequence 
number are needed to uniquely identify the version of 
item engineering data 50 and bill of material data 68 
pertaining to item A, which is affected by ECA. By 
cariying very limited versioned data, the volume of 
storage space needed for managing versioned data 
objects is considerably reduced. For example, there 
is no need to carry effectivity of versioned objects in 
item engineering data file 50 or bill of material compo- 
nent file 68 since the corresponding EC affected item 
instances in EC affected item file 16 contain the 



required effectivity information. Apart from the logical 
key, view identifier, insert sequence number and ext- 
ract sequence number, all other data elements shown 
in item engineering data file 50 and bill of material 

5 component file 68 are optional. 

Figure 5 provides an illustration of the effect of an 
engineering change notice, ECB, that changes the bill 
of material file 68 for assembly A in pre-release status 
in the engineering view without changing its 

10 associated data in item engineering data file 50. As 
indicated in bill of material component file 68, ECB 
replaces bill of material component D with 2 units of 
component E. The planned effectivity start date of "5- 
3-90" is associated with ECB in EC affected item file 

15 16. The actual effectivity date can occur later since 
component D is to be phased out by using up its exist- 
ing stock. It is assumed in the example that ECB 
supersedes ECA for assembly A in the engineering 
view. A new instance of EC affected item object is 

20 created with EC identifier "ECB", a view identifier 
"Engl", system generated design sequence number 
"8002", and corresponding effectivity information. A 
new instance of bill of material object is created for 
component item E with view identifier "Engl" and 

25 insert sequence number "8002". The quantity per 
assembly is recorded as 2 units. 

The view identifier and insert sequence number 
attributes identify the relationship between this bill of 
material object instance and the corresponding EC 

30 affected item instance for ECB. The previous bill of 
material instance for component D that was inserted 
by sequence number "8001" representing ECA is 
retained as extracted by ECB instead of physically 
deleting the component D record from bill of material 

35 file 68. The design sequence number 8002 is recor- 
ded as the extract sequence number for the previous 
bill of material instance. The previous bill of material 
instance was valid starting with the implementation of 
ECA and ending immediately prior to implementation 

40 of ECB. Note that a new instance is created only for 
component E since component items B and C, the 
other components of assembly A, remain valid and 
are un extracted The planning code for component D 
is changed from "normal" to "phase out" to indicate 

45 that the existing stock of component D will be used up 
before implementing the engineering change ECB at 
a time on, or later than, the planned effective date. In 
this embodiment; the component position identifier 
column is used to determine the correspondence be- 

50 tween replacing and replaced components. In Figure 
5, both components D and E have a component posi- 
tion identifier of 3. No changes are made to item 
engineering data file 50 and all unextracted data 
remain valid for ECB. 

55 The effect of promoting the status of an engineer- 

ing change affected item from one status to the next 
is demonstrated in Figure 6. The status of ECA for 
assembly item A in EC affected item file 1 6 is changed 
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from pre-release to released status. Concurrently, the 
security level for this EC affected item and all related 
version controlled data is changed automatically from 
05 to 04. The associated design, insert and extract 
sequence numbers are changed from 8001 to 6001 to 
facilitate subsequent user selection of version-con- 
trolled data. 

A method of allocating ranges of design sequ- 
ence numbers to different EC affected item status 
levels is illustrated in Figure 7. The latest version of 
an EC affected item related object or BOM related 
object is assigned automatically the next higher 
design sequence number available. Pre-release ver- 
sions of objects are assigned the highest range of 
sequence numbers. Progressively lower ranges of 
sequence numbers are assigned to released, accep- 
ted, effective and closed versions of objects. The 
rationale for this numbering scheme is that a pre-re- 
lease version of an object, identified by its logical key 
and view identifier, supersedes all released versions 
of the same object and, of necessity, is released later 
in time than previously released versions of the 
object. Within each status level, the next higher avail- 
able number within the applicable range is assigned 
to the most recent version of the object instance. The 
identical sequence number cannot be assigned to 
multiple object instances having the same logical key 
and view identifier. 

When an EC affected item is promoted to the next 
status level in progression, its design sequence num- 
ber and all related insert and extract sequence num- 
bers are changed to the next higher number available 
within the range of numbers allocated to the status 
level. This enables the use of simple queries to ret- 
rieve object instances satisfying the search criteria. A 
search can be made to return all instances of a data 
object for which the inserting or extracting version is 
earlier (or later) than a specified version. Similarly, a 
search could be made for all instances of an object for 
which the inserting version is later than or equal to a 
specified version, and the extracting version is later 
than or equal to the specified version. 

In Figure 8, engineering change notice ECC 
changes the item engineering data for item A in pre- 
release status in the engineering view, without chang- 
ing item A's bill of material data. The purpose of ECC 
is to change the standard unit of measure for assem- 
bly A from "each" to "pair" with a planned effectivity 
date of "7-5-90". The entry in EC affected item file 16 
for ECC and assembly item A indicates a design sequ- 
ence number of "8003" has been automatically assig- 
ned. A new instance of item engineering data is 
created and added to item engineering data file 50 
with a view identifier "Engl" and insert sequence 
number "8003". The previous instance of item 
engineering data is made inapplicable from ECC 
onwards by the extract sequence number "8003". No 
changes are made to the bill of material file 68 with all 



unextracted data remaining valid for ECC! 

Figure 9 illustrates the effect of changing the 
status for item A in ECA from release to accepted at 
a manufacturing plant location. The EC affected item 

5 data for item A in EC affected item file 1 6 represents 
unmodified data as released by the design laboratory. 
This data is copied over to a location affected item 
table 16' with the appropriate view identifier "Loci". 
Multiple manufacturing locations are supported on a 

10 single computer system with each location creating its 
own view of the location affected item and assigning 
the actual effectivity data; therefore, only a single 
copy of the EC affected item exists in EC affected item 
file 16. The EC-item status for the specific location is 

is changed to accepted, and the security level is 
changed from 04 to 03. The design sequence number 
is changed to "4001" in accordance with the rules set 
forth in Figure 7. Note, however, that this new design 
sequence number applies only to the manufacturing 

20 view of the item, and the engineering views contained 
in item engineering data file 50 and BOM component 
file 68 remain unchanged with the previously assig- 
ned insert/extract sequence numbers. 

After promoting the status of item A in ECA from 

25 released to accepted at manufacturing plant "Loci", 
a location view is created as indicated in Figure 10. A 
location view allows local restructuring of a bill of ma- 
terial at a manufacturing plant or production line. In 
the example, the bill of material for assembly item A 

30 is initially copied to create a new "Loci" view of the 
data as indicated by the last three entries in bill of ma- 
terial file 68. The security level has been changed 
from 04 to 03 to permit access to this data by the pro- 
duction planning function. 

35 Other implementations of view versions, such as 

for rework views, may create a view wherein the dif- 
ferences between the manufacturing bill of material 
and rework bill of material are recorded within the 
rework view. The version control logic 20 relates the 

40 design sequence number for the rework view to the 
design sequence for the manufacturing view on which 
the rework view is based. For this reason, "based on 
view" and "based on sequence number" attributes are 
included in the location affected item object in location 

45 affected item file 16'. These same attributes are 
included in the EC affected item objects in EC affected 
item file 16. This enables one engineering view to be 
based upon another engineering view in a recursive 
relationship. Multiple view versions can be stacked in 

so a preferential order so that a match can be searched 
for a particular selection in one view, and then in other 
views. 

A number of retrieval options are available to the 
design or manufacturing engineers at terminal 18 
55 when using version control logic 20 to interact with the 
relational data base files stored on DASD 40. Figure 
1 1 represents a screen display that is visible on ter- 
minal 18 during interactive processing. The user 
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enters item number, object name, and, as approp- 
riate, EC identifiers) and effective date(s). The first 
retrieval option, "applicable at specific EC level" is 
used primarily to perform update verifications and to 
select a level of EC related data to modify or delete. 
It can also be used to review data prior to updates at 
a particular EC level. The version control logic 20 
searches the versioned data files for data records 
satisfying the search criteria (1) that the inserting EC 
is the specified EC or an earlier one and (2) either the 
extracting EC is later than the specified EC, or the EC 
controlled object is unextracted. 

The second option, "affected by specific EC 
level", is used to review all updates made by a particu- 
lar engineering change. Version control logic 20 sear- 
ches the versioned data files for data in which either 
the inserting EC or the extracting EC is the specified 
engineering change. The third option, "inserted by 
specific EC level", is used to review updates made by 
a particular engineering change in order to do verifi- 
cations of bill of material data. The version control 
logic 20 searches the versioned data in which the 
inserting EC is the same as the specified EC. 

The next three options are related to the status 
progression of engineering changes. The "release 
only" option gives the engineer at the controlling loca- 
tion visibility to the latest level of EC data that has 
been sent out to remote locations or released to man- 
ufacturing. The version control logic 20 searches for 
versioned data in which the inserting EC has been 
released but the extracting EC has not been released. 
Manufacturing locations are given visibility to the lat- 
est level of data that has been accepted by the 
"accept only" option. The version control logic 20 
searches for versioned data in which the inserting EC, 
but not the extracting EC, has a corresponding status 
condition of accept or higher (i.e., effective or closed). 
The "closed only" option gives visibility to the lasted 
level of data which has been closed. The version con- 
trol logic searches the versioned data for data in which 
the inserting EC, but not the extracting EC, has a 
status condition of closed. 

The "latest design" option gives the engineer at 
the controlling location access to the most current 
design level of data, some of which may still be in pre- 
release status. The version control logic 20 searches 
for EC controlled object instances that are unextrac- 
ted. 

Options eight and nine apply to effective dates of 
engineering changes. The "specific effective date" 
option is used to determine the production version of 
the data as of the date specified by the user. The ver- 
sion control logic 20 searches for inserting EC's hav- 
ing an effective date on or before the specified date, 
and satisfying one of the following: (1) the EC control- 
led object instance is unextracted, (2) the effective 
date of the extracting EC is later than the specified 
date, or (3) no effective date has been assigned to the 



extracting EC. The "range of effective dates" option 
gives a composite view of the production level of data 
over a period of time specified by user input. The 
search criteria that must be satisfied are that the effec- 

5 tive date of the inserting EC is on or before the speci- 
fied end date (the 'To" date) and one of the following: 
(1) the EC controlled object instance is unextracted, 
or (2) the effective date of the extracting EC is later 
than the specified start date (the "From" date), or (3) 

w no effective date has been assigned to the extracting 
EC. 

Finally, the "effective between two EC's" option 
provides a composite view of the design level of the 
data between the starting and ending EC's specified 

is by the user. This option can serve a useful planning 
purpose, such as reviewing the engineering changes 
which have been accepted to decide when they 
should be made effective.. The search criteria used 
are that the inserting EC is earlier than or equal to the 

20 ending EC (the "To" EC) specified by the user, and 
either the EC controlled object instance is unextrac- 
ted, or the effective date of the extracting EC is later 
than the starting EC (the "From" EC) specified by the 
user. 

25 

Claims 

1 . A method for the control of versioned data objects 
30 affected by engineering changes in a computer- 
based information processing system in which a 
master item file resides on a non-volatile storage 
device, said method comprising: 

creating an engineering change notice that 
35 identifies at least one item in the master item file 

that is affected by an engineering change; 

creating an affected item record for said at 
least one item and storing the affected item 
record in an affected item file on the non-volatile 
40 storage device; 

determining each versioned data object 
that is affected by the engineering change and 
storing said each versioned data object along 
with a plurality of version control attributes in a 
45 version-related data file on said non-volatile stor- 

age device; and 

processing said a version-related data file 
in response to a search query by an authorized 
user. 

50 

2. The method of claim 1 wherein the affected item 
record includes an engineering change identifier, 
an item identifier, an affected item status, a view 
identifier, a design sequence number, a product 

55 identifier, a security level, and at least one effec- 

tivity attribute. 

3. The method of claim 1 wherein said plurality of 
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version control attributes include a logical key, an 
insert sequence number, and an extract sequ- 
ence number. 



9. The method of claim 2 including the step of auto- 
matically generating the design sequence num- 
ber when said engineering change notice is 
created wherein the design sequence number 
represents a unique attribute of said at least one 
item affected and has-a direct correlation to both 
the engineering change identifier and the affected 
item status. 

10. The method of claim 9 further including the step 
of automatically generating an insert sequence 
number for each versioned data object affected 
by said engineering change and stored in said 
version-related data file, said insert sequence 



sioned data object as the extract sequence num- 
ber. 

12. The method of claim 1 wherein said processing 
step includes: 

presenting an interface screen to said 
authorized user containing user-selectable 
search query options; 

selecting a search query option and iden- 
tifying a set of input parameters for said search 
query to collectively define a search strategy; 

searching said versioned data file for each 
versioned data object satisfying said search 
strategy; and 

retrieving said each versioned data object 
satisfying said search strategy and providing said 
retrieved versioned data object to said authorized 
user as the result of said search query. 

13. The method of claim 12 wherein the set of input 
parameters for said search query include the item 
identifier and an engineering change identifier, 
said engineering change identifier being entered 
as a pair of values to identify and to provide said 
authorized user with a composite view of the ver- 
sioned data objects that are effective between the 
range of engineering changes represented by 
said pair of values. 

14. The method of claim 12 wherein the set of input 
parameters for said search query include the item 
identifier and a specified date said specified date 
being entered as a pair of values to identify and 
to provide said authorized user with a composite 
view of the versioned data objects that are effec- 
tive between said range of specified dates. 

15. The method of claim 8 wherein said affected item 
record further includes a "based on view" attribute 

40 and a "based on sequence number" attribute. 

1 6. The method of claim 1 5 wherein multiple view ver- 
sions of said versioned data objects are created 
in which a first view version is based on a second 

45 view version which, in turn, can be based on a 

third view version, the "based on view" and 
"based on sequence number" attributes being 
used to associate said multiple view versions. 

1 7. A system for the control of versioned data objects 
affected by engineering changes in a computer- 
based information processing system having a 
processor, non-volatile data storage device con- 
taining a data base in which a master item file, an 
engineering change notices file, and an engineer- 
ing change affected item file are stored, and at 
least one device for input and output, said system 

* comprising: 



number being set to the corresponding design so 
sequence number resulting from creating the 
engineering change notice. 

1 1 . The method of claim 1 0 further including the step 

of identifying each versioned data object that is ss 
superseded by entering the design sequence 
number of the corresponding versioned data 
object that replaces each said superseded ver- 



4. The method of claim 3 in which said versioned s 
data object is item-related and stored in said ver- 
sion-related data file with the item identifier being 
used as the logical key. 

5. The method of claim 3 in which said versioned 10 
data object is bill of material related and has both 
an item identifier and a component identifier, and 
is stored in said version-related data file with a 
combination of the item identifier and the compo- 
nent identifier being used as the logical key. 15 

6. The method of claim 2 in which said at least one 
item affected is given an initial affected item 
status of pre-release, said at least one item affec- 
ted subsequently being promoted to a status of 20 
released, accepted, effective and closed as the 
said at least one item affected progresses 
through design, manufacturing and production. 

7. The method of claim 2 wherein said security level 25 
controls access to each of said versioned data 
objects and has a direct correspondence to said 
affected item status of each of said versioned 
data objects. 

30 

8. The method of claim 2 wherein the view identifier 
in said affected item record is used to identify and 
retrieve all unextracted versioned data objects 
representing the same view. 
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a first plurality of data files containing ver- 
sioned data objects that are item related; 

a second plurality of data files containing 
versioned data objects that are bill of material 
related; and 5 

version control logic means operating on 
said processor that is cooperative with said first 
and second plurality of data files and responsive 
to a search strategy provided by an authorized 
user using said device for input for retrieving ver- 10 
sioned data objects from said first and second 
plurality of data files satisfying said search 
strategy. 

1 8. The system of claim 1 7 wherein said version con- 15 
trol logic means provides data access authori- 
zation to versioned data objects contained in said 
engineering change affected item file, and in said 
first and second plurality of data files in response 
to requests from said authorized user based on 20 
the engineering change item status of said data 
records. 



19. The system of claim 17 wherein said first plurality 

of data files includes an item engineering data file 25 
containing item related versioned data objects 
having fields for an item identifier, an insert sequ- 
ence number, and an extract sequence number, 
said item identifier being used as a logical key, 
and said insert and extract sequence numbers 30 
being used by said version control logic means to 
selectively retrieve said item related versioned 
data objects satisfying said search strategy. 

20. The system of claim 17 wherein said second 35 
plurality of data files includes a bill of material 
component file containing bill of material related 
versioned data objects having fields for an item 
identifier, a component item identifier, an insert 
sequence number, and an extract sequence 40 
number, said item identifier and component item 
identifier forming a logical key, and said insert and 
extract sequence numbers being used by said 
version control logic means to selectively retrieve 

said bill of material related versioned data objects 45 
satisfying said search strategy. 
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